---title: "Transcrição da Prova Teórica 1" matricula: "20223006791" nome: "Pedro Cláudio Jacome" disciplina: "Gestão de Projetos de Software (GPS)" avaliacao: "Prova Teórica 1" data: "19/10/2026" nota_total: 22.9 legibilidade_global: "90%" classificacao: "Alta Legibilidade (90-100%)" observacoes_caligrafia: "Excelente prova em caneta azul, letra cursiva elegante e fluida. Respondeu a todas as 5 questões com riqueza técnica, incluindo aplicação inédita e precisa da fórmula de estimativa PERT tri-pontual no item 2.2." format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Avaliação Teórica 1 — Transcrição de Respostas ## Questão 1 — Ciclo de Vida e Fundamentos de Projetos * **Legibilidade da Questão:** 92% * **Gravidade de Leitura:** Normal ### 1.1 Projeto vs. Operação * **Resposta Manuscrita:** > Projeto. Projetos são definidos como um esforço temporário (com início, meio e fim) para a produção de um produto ou serviço. Em contraste, operações são contínuas e envolvem manutenção em tarefas regulares (sem fim). No exemplo acima: 1 - 'aplicação web': é um produto; 2 - 'Sprint': característica de projetos ágeis; 3 - implementação de ~~novas~~ features é aspecto de projetos. ### 1.2 Análise de Trade-off no Triângulo de Ferro * **Resposta Manuscrita:** > 1 - Substituir a previsão de tempo atual por uma mais realista; sacrificando o 'tempo' no Triângulo. > 2 - Alterar ~~o~~ o requisito de tempo mínimo de resposta; sacrificando o 'escopo' no Triângulo. ### 1.3 Ciclo de Vida do Projeto e Abordagem * **Resposta Manuscrita:** > ~~Ágil~~ Híbrido. Pois ele adota alguns métodos ágeis (como sprints), os objetivos são pré-definidos e já distribuídos nas milestones o que segue o padrão preditivo. --- ## Questão 2 — Escopo, EAP e Gestão de Backlog * **Legibilidade da Questão:** 90% * **Gravidade de Leitura:** Normal ### 2.1 Estrutura Analítica do Projeto (EAP) * **Diagrama / Elemento Visual:** ```text Professor Agente (100%) |-- CI/CD (20%) |-- Engine/core (50%) |-- Interface Web (30%) ``` * **Resposta Manuscrita:** > EAP é hierárquica porque os 'filhos' são os componentes necessários para a entrega dos 'pais'. É orientada a entregas pois as 'folhas' são sempre pacotes de entrega individuais, então para fazer 100% se deve fazer todas as entregas previstas. Ex.: Estabelecer conexão API Telegram; Estabelecer conexão API OpenAI; Criar o System Prompt. ### 2.2 Especificação de Issues de Backlog e Estimativas * **Resposta Manuscrita:** > 1 - 'Estabelecer conexão API Telegram'; Desc.: Conseguir uma chave de API e escrever o código para a conexão do Bot ao Telegram; C.A.: CI/CD passado, avaliado por outra pessoa; Est.: `(1 + 4×2 + 6)/6 = 2.5 horas`. > 2 - 'Criar o system prompt'; Est.: `(2 + 4×4 + 12)/6 = 5 horas`. > A segunda estimativa é maior porque o system prompt é um documento longo e precisa de mais avaliação. O outro é só obter a chave API e escrever código para testar ela. A primeira issue dá mais detalhes e é mais útil para desenvolvedores, mas levou mais tempo (esforço) para fazer. ### 2.3 Milestones vs. Sprints no Modelo Ágil * **Resposta Manuscrita:** > Milestones são um método de controlar a quantidade de tempo para executar as tarefas do projeto. Isso é similar a Sprints mas não completamente substitui elas. Sprints tem carácter cíclico, enquanto milestones são tarefas pré-definidas. > Kanban sem sprints pode ser adequado a projetos pequenos ou que possuem baixa interdependência entre componentes. Pois caso contrário, desenvolvedores podem focar demais em uma parte só do projeto, ou inicialmente ficar em tarefas não-essenciais. Isso pode fazer demorar a aparecer um artefato inicial viável o que esconde potenciais problemas no design. --- ## Questão 3 — Qualidade e Engenharia de Software com IA * **Legibilidade da Questão:** 90% * **Gravidade de Leitura:** Normal ### 3.1 Definição de Pronto (DoD) e Pipelines de CI/CD * **Resposta Manuscrita:** > DoD explica como um elemento no projeto está completo, o que é necessário para marcar como 'feito' no Kanban. Não, pois CI/CD é uma etapa requerida para a compleção de uma tarefa. ### 3.2 Custo da Qualidade (CoQ) * **Resposta Manuscrita:** > a) prevenção; b) avaliação; c) falha externa; d) falha interna. > Falha Externa. Porque é o mais difícil de consertar; tem mais urgência (diversos custos de outras áreas da empresa, e não temos benefício de ser planejado); e pode afetar a percepção externa do produto e da empresa, perdendo clientes. ### 3.3 Heurística 1:10:100 e Testes em Software com IA * **Resposta Manuscrita:** > A heurística diz que a escala do custo de corrigir o mesmo erro é 1x se for encontrado durante prevenção, 10x se for encontrado durante avaliação, e 100x se for encontrado por alguma falha. > Ela não se aplica bem a IA pois com IA há altos custos de API e gastar esses recursos em testes quando você não está ganhando dinheiro com o seu produto pode te afundar. Então não se aplica a IA em todos os aspectos mas ainda assim se deve fazer testes de segurança (anti-prompt injection). --- ## Questão 4 — Gestão de Riscos e Segurança * **Legibilidade da Questão:** 90% * **Gravidade de Leitura:** Normal ### 4.1 Classificação do Evento e Matriz de Riscos * **Diagrama / Elemento Visual:** * Marcou no quadrante Médio (Probabilidade Baixa × Impacto Médio/Alto). * **Resposta Manuscrita:** > Foi um problema. Pois riscos são definidos pela sua chance de ocorrer, quando um risco ocorre, ele é um problema. A posição no gráfico depende do contexto. O uso temporário de uma chave de API por atores externos pode ser de baixo impacto ou alto conforme o tamanho da empresa. Neste caso eu coloquei como se fosse no meu projeto de Professor I... > *(Continuação no espaço de rascunho da pág. 6):* ...em que o impacto de outros usarem a chave é alto por não termos muitos recursos; mas a chance é baixa pois temos poucas pessoas com acesso à chave. ### 4.2 Resposta a Incidentes e Defesa em Profundidade * **Resposta Manuscrita:** > 1 - Resetar a chave no OpenAI; 2 - Deletar o commit com a chave do histórico do GitLab; 3 - Limitar o acesso à página do GitLab. Ação preventiva seria periodicamente resetar a chave no OpenAI e substituir ela. Assim as chaves antigas param de funcionar e mesmo se a nova vazar o efeito será temporário. ### 4.3 Modelagem de Ameaças em IA e Documentação Decisória * **Resposta Manuscrita:** > Causa: usuário tentou prompt injection; prob.: alta; impacto: baixo; mitigação: escrever o system prompt de modo que ele circumente e entenda esse risco; contingência: banir o usuário. Usar um modelo bom, manter respostas curtas. Essas decisões devem ser marcadas por um ADR, que registra as decisões na documentação. Os outros métodos são inapropriados para isso. --- ## Questão 5 — Comunicação, Partes Interessadas e Conflitos * **Legibilidade da Questão:** 88% * **Gravidade de Leitura:** Normal ### 5.1 Canais de Comunicação e Rastreabilidade Decisória * **Resposta Manuscrita:** > Comunicação síncrona é útil para comunicados urgentes ou discussões, mas tem a desvantagem de requerer compromisso dos envolvidos. Assíncrona é boa para distribuição de tarefas e rastreamento e documentação, mas tem a desvantagem de ser devagar e não garantir entendimento. O melhor método para isso é ADR, que é um tipo de documentação (assíncrona) que mantém informações sobre as decisões feitas. ### 5.2 Engajamento de Partes Interessadas (Poder × Interesse) * **Diagrama / Elemento Visual:** * **Manter Satisfeito:** 4 (Provedor API), 5 (Coordenação de curso) * **Gerenciar de Perto:** 2 (Professor) * **Monitorar:** 1 (Alunos) * **Manter Informado:** 3 (Equipe de desenvolvimento) * **Resposta Manuscrita:** > O professor é o mais relevante. O professor deve ter acesso ao progresso do projeto por meio de monitoração do progresso das milestones, em que o time use a documentação para definir o progresso feito, os problemas encontrados e os planos para mitigar esses problemas. ### 5.3 Resolução de Conflitos e Modelo de Thomas-Kilmann * **Resposta Manuscrita:** > Já que o cliente está no quadrante 'manter satisfeito' e o time está em 'manter informado', se deve fazer o que o cliente está pedindo; mas o time deve antes, fazer uma reunião com os clientes para analisar os riscos de alucinação e os métodos para mitigar isso. > Decisões ruins: > 1 - Fazer o que o time quer e ignorar os clientes. > 2 - Fazer o que os clientes querem sem antes analisar as opções e discutir com o time.